In recent years there has been rapid development in emerging technology regarding “intelligent” mobile devices capable of running a variety of applications. However, the advancements in these devices have also led to higher costs and continued problems with a myriad of deficiencies related to intelligent mobile devices (for example, battery power, network bandwidth).
Examples of some of these deficiencies include limitations regarding battery power, network bandwidth and availability, device temperature, and latency sensitive applications. The following is an example to illustrate the problem in a practical manner, but these types of problems are widespread in relation to many areas.
The Software AG ARIS web product suite is one of the market's leading business process management tools. Customers use ARIS to document and analyze their internal processes and organization. The ARIS Connect Web Platform (a HTML/JavaScript based tool) provides a set of RIAs (Rich Internet Applications), and a mass of JavaScript based business logic, allowing the users to browse, read, create and write their business processes using a web browser. An example of one of these applications is the ARIS web modeling tool shown in FIG. 6.
Making tools and services used daily in businesses, such as the ARIS web model 601, accessible via mobile devices is becoming increasingly more crucial and important. The ability to be constantly connected to the tools and services of our daily business increases mobility and efficiency of the business users and makes businesses more flexible and competitive. In this context, battery life and the efficient usage of the CPU has become an important success factor for all web-based applications delivered over the web to mobile devices. However, the functional range of web application increases from day to day and more and more business applications require complex calculations to support the numerous daily business use cases.
A common and simple approach to solve this conflict, used by most of the current web based applications, is to shift long and expensive (in terms of CPU and battery usage) calculations to the server-side part of the web application. An example could be to shift the expensive routing algorithm execution of a car navigation application from to mobile device to the server-side part of the application. However, such an approach has significant disadvantages:
Costs. Shifting the execution of complex and expensive calculations (in terms of CPU and battery usage) to the server-side of the application produces additional costs for the server infrastructure. In particular the costs for cloud-based infrastructures could significantly increase if third-party vendors host the infrastructure.
Inflexible. Once the execution of complex and expensive calculations has been moved to the server-side, the execution cannot be moved back to the client device. If the mobile device is connected to an external power source or has sufficient battery capacity left it is not necessary to move complex calculation to the server-side. In such cases, distributing the calculation load between all connected mobile devices would be desirable and reduce the workload and costs for the server infrastructure.
Since, all existing approaches are solving only the problem of shifting application code/logic from client-side to the server-side or vice-versa using common paradigms, the following discussion provides an overview of same frameworks and systems making use of these paradigms and explains why they are not solving the problems previously described.
1. Systems/Frameworks Using Remote Procedure Calls (RPCs)
A remote procedure call is an inter-process communication that allows a client application in a client-server scenario to execute a subroutine or procedure on the server-side and to get the result back, while hiding all details of the necessary data transformation, unpacking and protocol handling for the remote interaction.
Systems and frameworks making use of this approach handle all that is necessary to make the remote interprocess communication as seamless and transparent as possible. In addition they provide powerful solutions for transferring the input data, necessary for the execution of remote procedures, from the client to the server by having as few restrictions as possible on the data model. Some frameworks providing RPC solutions include: (1) Spring Web MVC framework and (2) Java Remote Method Invocation (Java RMI).
Existing RPC systems and frameworks focus on the seamless and transparent execution of remote procedures. They do not provide any seamless and transparent solution for switching the execution of an application procedure from the client-side to the server-side if required to keep the services available as long as possible on the mobile device.
2. Systems/Frameworks Using Cross-platform Runtime Environments
Cross-platform runtime environments are computer software solutions and systems, which allow computer software to be executed on multiple computer platforms and architectures. For example, a cross-platform environment allows an application to run on Microsoft Windows Server on x86 architecture or on Android Platform on mobile devices based on a totally different architecture by only writing the application code once.
Some of these environment systems do not even require recompiling the application code and allow the use a single programming language for all supported platforms. Web applications are typically described as cross-platform because they can be executed from various web browsers running on different operating systems and devices. If web applications are paired with cross-platform runtime environment systems which support the browser's programming language (for example, JavaScript) on the server-side, this leads to systems which can easily and seamlessly shift from the client to the server and vice-versa.
Systems and frameworks making use of this approach handle all the necessary stuff to make the cross-platform execution of the application logic as seamless and transparent as possible. The main focus of these systems is the ability to write the application code only once and to use it on any platform wherever needed within the target system architecture. Some frameworks providing cross-platform/language solutions: (1) Node.js and (2) Apache Thrift.
These systems do not provide any seamless and transparent solution for switching the execution of an application procedure from the client-side to the server-side if required to keep the services, depending on this procedure, available as long as possible on the mobile device.
3. Missing Approaches in Traditional Systems
Existing solutions have their focus on the seamless and transparent execution of an application logic located on the server-side by using an inter-process communication (RPC solutions) or the shifting of client-side code to the server-side or vice versa (cross-platform solutions). These approaches assume that it is possible to make a decision at the beginning of a project regarding whether specific application logic has to be executed on the client-side or the server-side. These solutions have the following disadvantages and do not cover the following aspects:
Inflexible. Once a decision has been made on executing specific application logic on the client-side or server-side, there is no possibility to shift this logic back on the client-side or server-side at runtime if requirements or external influences of the application change. A shift of the application logic always requires changes on the application implementation and additional coding efforts.
Does not Fit the Requirements of Mobile Devices. Mobile devices are characterized by less powerful processing units and a limited power source (the battery). For the end user this means that he has to make a decision for which application and use cases he wants to spend the limited resources. In most cases this decision depends on a variety of different factors and changes from time to time. If the battery of the device is fully charged or an external power source is available, the user perhaps has no problem executing expensive calculations on the device. However, in cases when there is no external power source available and it is important for the user to have other use cases (for example, to be reachable via messaging tools) available as long as possible, the user would prefer to execute such calculations on the server-side. However, from a cost-benefit perspective of the service or use case provider it would be preferable to execute as many as possible of the calculations on the mobile-device-side to reduce the costs for the server infrastructure and to spread the calculation load. A seamless, transparent and implementing effort reducing solution covering these aspects, problems and conflicts is not provided by the traditional approaches.
Higher Implementation Costs. Handling the requirements of mobile device application use cases requires a profound knowledge of different mobile device application programming interfaces to provide a battery status based behavior for the execution of application logic. This kind of hardware-near implementation is outside of the daily implementation tasks of a typical web developer, especially with regard to web based applications running in a web browser.
This leads to additional and excessive implementation efforts which are not related to the business logic of the application. Existing solutions do not provide a comfortable and implementation effort reducing approach hiding these aspects so that the web developer can focus on the actual application business logic.
One or more embodiments discussed herein can address the aforementioned problems with traditional systems, by running applications that automatically detect these deficiencies in real time and dynamically adjusting the environment in which the application runs (for example, switching it from the mobile device to the server and if necessary back again) to overcome a variety of deficiencies. The present system allows executing the application logic of browser-based mobile applications on the mobile devices themselves or the server-side part of the application, depending on the battery status of the mobile device. This happens in a more universal, transparent, simple and less costly way than the traditional approaches.